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Abstract. Flow- and context-sensitive pointer analysis is generally considered 
too expensive for large programs; most tools relax one or both of the require- 
ments for scalability. We formulate a flow- and context-sensitive points-to anal- 
ysis that is lazy in the following sense: points-to information is computed only 
for live pointers and its propagation is sparse (restricted to live ranges of respec- 
tive pointers). Our analysis also: (£) uses strong liveness, effectively including 
dead code elimination; (if) afterwards calculates must-points-to information from 
may-points-to information instead of using a mutual fixed-point; (Hi) uses value- 
based termination of call strings during interprocedural analysis (which reduces 
the number of call strings significantly). 

A naive implementation of our analysis within GCC-4.6.0 gave analysis time 
and size of points-to measurements for SPEC2006. Using liveness reduced the 
amount of points-to information by an order of magnitude with no loss of pre- 
cision. For all programs under 30kLoC we found that the results were much 
more precise than gee's analysis. What comes as a pleasant surprise however, 
is the fact that below this cross-over point, our naive linked-list implementation 
is faster than a flow- and context-insensitive analysis which is primarily used for 
efficiency. We speculate that lazy flow- and context-sensitive analyses may be not 
only more precise, but also more efficient, than current approaches. 



1 Introduction 

Interprocedural data flow analysis extends the scope of analysis across procedure bound- 
aries to incorporate the effect of callers on callees and vice-versa. The efficiency and 
scalability of such an analysis is a major concern. The precision of such an analy- 
sis requires flow-sensitivity (associating different information with distinct control flow 
points) and context-sensitivity (computing information depending upon the calling con- 
text). Sacrificing precision for scalability is a common trend in interprocedural data flow 
analysis. This is more prominent in pointer analysis in which the size of information 
could be large. Flow- and context-sensitive pointer analysis is considered prohibitively 
expensive and most methods relax one or both of the requirements for scalability. 

We formulate a flow- and context-sensitive points-to analysis that is lazy: points-to 
information is computed only for the pointers that are live and the propagation of points- 
to information is sparse in that it is restricted to live ranges of respective pointers. We 
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Let (a, b) at a program point denote 
that a points-to b at that program 
point. Then, 

- 2 is live at the exit of 9 which 
makes w live at the exit of 
3. Hence we should compute 
(w, x) in 3 and thereby (z, x) 
in 9. This causes x to be live 
because of *z in 12. Hence we 
should compute (x, y) in 2 and 
(z,y) in 12. 

- (w,x) and (x, y) should not be 
propagated to 5, 6, 7 because 
w, x are not live in these nodes. 

Fig. 1. A motivating example for lazy points-to analysis, its supergraph representation and some 
observations. The solid edges in the supergraph represent intraprocedural control flow while 
dashed edges represent interprocedural control flow. 

use strong liveness which identifies the pointers that are directly used or are used in 
defining pointers that are strongly live. Thus strong liveness incorporates the effect of 
dead code elimination on liveness and is more precise than simple liveness. 

Fig. [T]provides a motivating example for lazy pointer analysis. By printing z, the 
main procedure makes z live at node 12 after the call to procedure p. This makes z in 
node 12 live. This in turn makes w live in node 9 and then in 3 resulting in the points-to 
pair (w, x). This pair is propagated to 12 giving the pair (z, x). When this information 
becomes available in 12, x becomes live. This liveness is propagated to 2 giving the pair 
(x,y). Eventually we get the pair (z,y) in 12. Figures [8] and [9] give fuller detail after 
formulating lazy pointer analysis interprocedurally. Here we observe the following: 

- Lazy computation. Points-to pairs are computed when the pointers become live. 

- Sparse propagation. Pairs (x, y) and (w, x) are not propagated beyond the call to p 
in the main procedure in spite of the fact that x or w are not modified in p. 

- Flow sensitivity. Points-to information is different for different control flow points. 

- Context sensitivity, (z, x) holds only for the inner call to p made from within p but 
not for the outer call to p made from within the main procedure. Thus in spite of z 
being live in 6, (z, x) is not propagated to 6 but (z, y) is. 

We propose a novel data flow framework that employs an interdependent formula- 
tion for discovering strong liveness and points-to information for pointer variables. This 
framework computes must-points-to information from may -points-to information with- 
out requiring an additional fixed-point computation. At the interprocedural level, flow- 
and context-sensitivity is ensured by using value-based termination of call strings. 

Our findings conclusively demonstrate that instead of achieving scalability by com- 
promising on precision, it is far better to contain the explosion of information by clearly 
distinguishing between the information that is relevant from the information that is not 



main( ) 
{ x = &y; 
w = &x; 

p(); 

print z; 
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P() 

{ if(-) 
{ Z = w; 

P(); 

z = *z; 
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Fig. 2. Typical data flow equations for some procedure p. 



relevant. Since pointer information is required to uncover the data items that are ac- 
cessed indirectly or functions that are invoked indirectly, it is relevant only when there 
is some use of a pointer. We show that this change in perspective provides significant 
benefits in terms of time and space requirements of pointer analysis. 

The rest of the paper is organised as follows: Section [2] reviews the background. 
Section [3] formulates the mutually dependent liveness and points-to analysis at the in- 
traprocedural level. Section [4] formalises and proves some important properties of our 
analysis. It is lifted to interprocedural level in Section|5] Section|6]discusses the related 
work while Section|7]presents the empirical data. Section[8]concludes the paper. 

2 Background 

This section reviews intra- and interprocedural data flow analysis and pointer analysis. 

Overview of Data Flow Analysis. Data flow analysis is formulated in terms of data 
flow equations that describe how the required data flow information can be computed 
for a statement. The set of data flow values, the functions to compute them and the 
operation to merge them are described by a data flow framework. 

Unlike the classical view that treats a data flow framework and its instance as 
distinct !! 1 12I3I4I5H , we view a data flow framework parameterised by a program because 
the data flow values and the functions that manipulate them depend on the program be- 
ing analysed. Formally, a data flow framework is a tuple (Lg, Hg,Fg) |6| where G is 
an unspecified graph representing a program, Lg is a meet semilattice representing the 
data flow values relevant to the analysis, and Fq is a set of admissible flow functions 
from Lg to Lg- We require all strictly descending chains in Lg to be finite. I~Ig is the 
meet operator of Lg- We require the flow functions in Fg to be monotonic. 

At the intraprocedural level, a procedure is represented by a control flow graph 
(CFG) whose nodes represent program statements and edges represent control transfers. 
A CFG for procedure p must satisfy the following requirements: there must be a unique 
entry node start p with no predecessor and a unique exit node end p with no successor, 
each node n must be reachable from startp, and end p should be reachable from each 
node. At the interprocedural level, a program is represented by a supergraph which 
connects the CFGs by interprocedural edges. A call to procedure p at call site i is split 
into a call node Ci and a return node ri with a call edge Cj — > Startp and a return edge 
end p — > ri.ln examples we number nodes in the CFG in reverse post-order and assign 
contiguous numbers across procedures. Fig.Q]provides an example of a supergraph. 
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Data flow equations (Fig. |2]i define data flow variables ln n and Out n which rep- 
resent the data flow information associated with the entry and exit points of node n. 
In n , Oilt n S La and /„ 6 Fq- The boundary information Bl represents the data flow 
information at the procedure entry for forward analysis and procedure exit for backward 
analysis. Its value is governed by the semantics of the information being discovered. In- 
terprocedural analysis eliminates the need for a fixed Bl (except for arguments to main) 
and computes it from the calling contexts during the analysis. 

Iterative methods solve the data flow equations by refining the values starting from a 
conservative initialisation of T. Round robin methods traverse the CFG in a fixed order; 
work list methods maintain a list of the nodes whose values are to be recomputed. 



Interprocedural Data Flow Analysis. A supergraph contains control flow paths which 
violate nestings of matching call return pairs (e.g. 1-2-3-4-8-13-11 for the supergraph 
in Fig.[TJ. Such paths correspond to infeasible contexts. An interprocedurally valid path 
is a feasible execution path containing a legal sequence of call and return edges. 

A context-sensitive analysis retains sufficient information about calling contexts to 
distinguish the data flow information reaching a procedure along different call chains. 
This restricts the analysis to interprocedurally valid paths and ensures propagation of 
information from a callee to appropriate call sites. A context-insensitive analysis does 
not distinguish between valid and invalid paths effectively merging data flow informa- 
tion across calling contexts. Although the resulting information is provably safe, it is 
often imprecise. Recursive procedures have potentially infinite contexts, yet context- 
sensitive analysis is decidable for data flow frameworks with finite lattices and it is 
sufficient to maintain a finite number of contexts for such frameworks. However, this 
number is combinatorially large even for non-recursive programs. Flow-insensitive ap- 
proaches disregard intraprocedural control flow for efficiency. Instead of information 
being associated with each program point, a single summary is computed. Although the 
summary information is provably safe, it is imprecise. A flow-sensitive analysis honours 
the control flow and computes data flow information separately for each program point. 

We use a flow- and context-sensitive approach called the call-strings method II7I6I8I . 
It embeds context information in the data flow information and ensures the validity of 
interprocedural paths by maintaining a history of calls in terms of call strings. A call 
string at node n is a sequence c\c% . . . Ck of call sites corresponding to unfinished calls 
at n and can be viewed as a snapshot of the call stack. A denotes an empty call string. 
Some call strings for our supergraph in Fig.[TJare: A, C\, C\Ci, C1C2C2 etc. 

Call string construction is governed by interprocedural edges. Let a be a call string 
reaching procedure p. For an intraprocedural edge m — > n in p, a reaches n unmodified. 
For a call edge Cj — > Start q where c; belongs to p, call string aci reaches start q . For 
a return edge end p — > rj where rj belongs to a caller of p, if the last call site in u 
is Cj then the longest prefix that excludes Cj reaches the call site corresponding to rj . 
If the last call site in a is not Cj, the call string and its associated data flow value 
is not propagated to the call site corresponding to rj . This ensures that the data flow 
information is only propagated to appropriate call sites. In a backward analysis, the call 
string grows on traversing a return edge and shrinks on traversing a call edge. 
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Fig. 3. An example of flow-sensitive intraprocedural points-to analysis. 



The augmented data flow information is a pair (a, d) where d is the data flow value 
propagated along call string a and is modified by an intraprocedural edge only. A work- 
list-based iterative algorithm is used to perform the data flow analysis. The process ter- 
minates when no new pair (a, d) is computed; merging the data flow values associated 
with all call strings reaching node n gives the final data flow value at n. This method 
computes a safe and precise solution because it matches call and return nodes in a path 
thereby excluding interprocedurally invalid paths and traversing valid paths only. 

In non-recursive programs, since the call strings are acyclic (no call site occurs 
multiple times), their number is finite and all of them are generated during analysis. 
However, in recursive programs, new call strings are generated with every visit to a call 
node involved in recursion. In such cases, the number of call strings considered must be 
bounded using explicit criteria. For computing a safe and precise solution, the full call- 
strings method [7| requires construction of all call strings of length up to K x (|L| + 1) 2 
where K is the maximum number of distinct call sites in any call chain and L is the 
lattice of data flow values. For bit-vector frameworks, we need to consider only those 
call strings in which a call site appears at most thrice 0. Since these numbers are 
very large for practical programs and we use a recent variant in which the termination 
of call-string construction is based on the equivalence of data flow values instead of 
precomputed length bounds |8 6|. This allows us to discard call strings where they are 
redundant, and regenerate them when required. For cyclic call strings representing paths 
in recursion, regeneration facilitates computation of data flow values without explicitly 
constructing most of the call strings. This reduces the space and time requirements of 
the analysis dramatically without compromising on safety or precision. 



Pointer Analysis Two forms of pointer analysis are extant: alias analysis identifies 
pairs of address expressions that both hold the address of a given location. Points-to 
analysis identifies locations whose addresses are held by pointers. May- and must- vari- 
ants of both exist. This paper restricts itself to points-to analysis. 
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Points-to relations are computed by identifying locations corresponding to the left- 
and right-hand sides of a pointer assignment and taking their cartesian product 1101111 . 
The points-to pairs of locations that are modified are removed. May-points-to infor- 
mation at n contains the points-to pairs that hold along some path reaching n whereas 
must-points-to information contains the pairs that hold along every path reaching n 
(hence a pointer can have at most one pointee) [11 1. Fig. [3] provides an example of 
flow-sensitive points-to analysis. For this example, an inclusion-based flow-insensitive 
analysis lfl2l concludes that (p, r), (p, s), (q, r), (r, s), (s, r) hold at all program points. 
An equality-based flow-insensitive analysis 1131 additionally computes (q, s). 

3 Lazy Pointer Analysis 

We consider the four basic pointer assignment statements: x — Szy, x = y, x = *y, 
*x — y using which other pointer assignments can be rewritten. We also assume a use x 
statement to model other uses of pointers (such as in conditions). 

3.1 Notation and Basic Definitions 

Let V denote the set of variables (i.e. "named locations"). Some of these variables (those 
in P C V) can hold pointers to members of V. Other members of V hold non-pointer 
values. These include variables of non-pointer type such as int. NULL is similarly 
best regarded as a member of V — P, finally a special value '?' in V — P denotes an 
undefined location. This represents the value of an uninitialised pointer declaration, e.g. 
int *x ; . At the moment it is simplest to think of '?' as being NULL as in Java rather 
than C, so that indirecting on it terminates execution (Section [3~4l explains this). 

Points-to information is a set of pairs (x, y) where x G P is the pointer of the pair 
and y £ V is a pointee of x and is also referred to as the pointee of the pair. The pair 
(x, ?) being associated with program point n indicates that x may not contain a valid 
address along some potential execution path from start p to n. 

The liveness information for statement n is denoted by the data flow variables Lin n 
and Lout n , the may-points-to information is denoted by Ain n and Aout„ , and the must- 
points-to information is denoted by Uin„ , Uout n . Instead of being calculated as a mu- 
tual fixed point with Ain n , Aout n , in our framework Uin„ , Uout„ are computed after- 
wards from Ain n , Aout n . Note that liveness propagates backwards (transfer functions 
map out to in) while points-to propagates forwards. 

Let V(S) denote the powerset of S. Then C = (V(P), 2) is the lattice of live- 
ness information. Note that this means that we do not track the liveness of non-pointer 
variables because their liveness is not relevant to points-to analysis. The lattice of may- 
points-to information is A = (V(P x V),_D). The overall lattice of our data flow values 
is the product C x A having partial ordeiQ 

V(Zi, ai), (l 2 , a 2 ) £ CxA, (h,ai) E (Z 2) a 2 ) o (h E h) A (a x C a 2 ) 

(h 2 h) A (at Da 2 ) 

3 We use the original data flow greatest fixpoint formulation where T constitutes the initial value 
rather then the abstract-interpretation-style least fixpoint formulation which iterates from _L. 
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The T element of the lattice L x A is (0, 0) and the _L element is (P, P x V). 
We use standard algebraic operations on points-to relations: 

- For a given relation R C P x 1/ and some set X, relation application (R X) is de- 
fined as R X — {v | u G X A (u, v) G R} and relation restriction (R\ x ) is defined 
as R\ x = {(u,v) G R\ u G X}. 

- Given relations SCixB and T C B x C, relation composition T o S Q A x C 
is defined as T o 5 = {(m, iu) | (u, «) € 5 A (u, w) G T}. 

However, since R C P x V, we need to take a little more care formalising Ro R 
because of the mismatch between the sets. We adopt the conventional approach of using 
the inclusion map: since PC V, by inclusion of relations we regard the leftmost R as 
being a subset of V x Ineffectively coercing P x 1^ into V x V). To distinguish it from 
the usual composition, we denote it as RoR. Note that the result is a subset of P x V. 

Consider V = {a, b, c,d,e, f,g,?} and P = {a, b, c, d, e}. Let relation R C P x V 
be {(a, b), (a, c), (b, d), (c, e), (c, g), (d, a), (d 7 g), (e, ?)}. Consider Z = {a, c}. Then: 

# Z = {b,c,e,g} 

R \z = {( a > & ); (°> c )> ( c > e )> ( c >5)} 
R 2 = RoR = {(a,d),(a,e),(a,g),(b,a),(b,g),(c,l),(d,b),(d,c)} 

3.2 What is Lazy Pointer Analysis? 

We formulate liveness and points-to analysis so that points-to information is computed 
relative to liveness. In particular a points-to pair for a pointer is generated only if the 
pointer is live. Hence {x=&y; return 3;}and{x=&z; return 3 ;} calculate 
the same (empty) points-to information as x is dead after the assignment. Further, live- 
ness information is similarly computed relative to points-to information, using strong 
liveness J5) instead of the more common simple liveness. In strong liveness, the vari- 
ables read in an assignment statement are considered live only if any of the variables 
defined by the statement are known to be live. In simple liveness all variables that are 
read are considered live regardless of the liveness of the variables that are defined. This 
formulation directly allows a joint liveness-and-points-to analysis Further, 

- The propagation of points-to information is sparse in the CFG; a points-to pair 
(x, y) is propagated only along those live ranges of x that include the statement in 
which this pair is generated. In contrast, the propagation of liveness information is 
dense because it is propagated to all possible program points. 

- Must points-to information is computed incrementally from the may points-to in- 
formation without requiring an interdependent fixed point computation. This is 
quite unlike 1101111 . 

We use the example of Fig. [3] as a motivating example for our intraprocedural for- 
mulation and make the following observations: 

- p is live at the exit of 2 because of its use in 3 and 4. q becomes live because it is 
used in defining p in 2 and p is live at the exit of 2. Hence (q, r) should be generated 
in 1 and should be propagated everywhere except in 7 where q is not live. 
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- Since (q, r) holds in 2, (p, r) should be generated and should be propagated to only 
3 and 4 because p is not live anywhere else. 

- r becomes live in 3 because (p,r) holds in 3. Its liveness is propagated to 1, 2, 
and 6. It is not live in 4, 5, and 7. (r, s) should be generated in 6 and should be 
propagated to 2 and 3 but not beyond because r is not live beyond 2 and 3. 

- s is not live anywhere hence (s, r) should be not generated. 

3.3 Defining Lazy Pointer Analysis 

Fig. 2] provides the data flow equations for lazy pointer analysis. They resemble the 
standard data flow equations of liveness analysis and pointer analyses [6|. However, 
there are three major differences: 

- liveness and may-points-to analyses depend on each other (bi-directional), 

- lazy computation and sparse propagation are directly captured in the equations, and 

- must-points-to information is computed from may-points-to information (i.e. fixed- 
point computation is not performed for must points-to analysis). 

The initial value (T of the corresponding lattices) used for computing the fixed point is 
for both liveness and may-points-to analyses. For liveness Bl is and defines Lout enC j ; 
whereas for points-to analysis, Bl is Lin n x {?} and defines Ain s t ar t . This reflects that 
no pointer is live on exit or holds a valid address on entry to a procedure. 

Extractor Functions. The flow functions occurring in Equations and © use ex- 
tractor functions Def n , Kill n , Ref n , and Pointee n which extract the relevant pointer 
variables for statement n from the incoming pointer information Ain n . These extractor 
functions are inspired by similar functions in II 1 01 111 . 

Def„ examines the left hand side an assignment statement to find the pointer vari- 
ables which may be defined by the statement to hold new addresses. Pointee n computes 
potential pointees by examining the right hand side of n. Thus the new points-to pairs 
generated for statement n are Def n x Pointee n (Equation |6). Sparse propagation of 
points-to pairs is ensured by restricting the collected points-to pairs to live pointers. 
Ref n computes the variables that become live in statement n. Condition Def n D Lout n 
ensures that Ref n computes strong liveness rather than simple liveness. As an exception 
to the general rule, x is considered live in statement *x = y regardless of whether the 
pointees of x are live otherwise, the pointees of x would not be discovered. For exam- 
ple, given {x=&a; y=3; *x=y; return; }, (x, a) cannot be discovered unless x 
is marked live. Hence liveness of x cannot depend on whether the pointees of x are live. 
By contrast, statement y = *x uses the liveness of y to determine the liveness of x. 

Kill n identifies pointer variables that are definitely modified by the execution of 
statement n. This information is used for killing liveness as well as points-to informa- 
tion. For statement *x = y, KHI n depends on Ain n which is filtered using the function 
Must. The filtering criteria ensures that when no points-to information for x is avail- 
able, we conservatively assume that all pointers are modified by statement *x = y. This 
is consistent with the initial values of may-points-to information and liveness both of 
which are 0. Given some points-to information for x, Must uses the number of pointees 
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Given relation R C P x V (either Ain n or Aout n ) we first define an auxiliary extractor function 

V K«} = 0)v(fl| { , } = {(a:,?)}) 
M (J?| w = {(x,y)}) A(y#?) ( 2 ) 



Must(R) = {J {x} x < 

16P 



otherwise 
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Fig. 4. Intraprocedural formulation of lazy pointer analysis. 



(3) 
(4) 

(5) 

(6) 



to determine whether to perform a weak update or a strong update: when a; has multiple 
pointees we cannot be certain which one will be modified because x points to different 
locations along different execution paths reaching n. In this case we employ weak up- 
date which does not allow any data flow information to be killed. By contrast, when x 
has a single pointee other than '?', it indicates that x points to the same location along 
all execution paths reaching n and a strong update can be performed^ 



4 Note that this conclusion is only possible because 6/ is Lin n x {?}. This value of Bl ensures 
that if there is a definition-free path from the Startp statement to statement n, we will get (a;, ?) 
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{q,r}L,{(q,r),(r,s)} A - 



Second round of liveness and points-to 



Fig. 5. Intraprocedural lazy points-to analysis of the program in Fig. [5] Shaded boxes show the 
liveness and points-to information suffixed by L and A respectively. 



Motivating Example Revisited. Fig. [5] gives the result of lazy pointer analysis for 
our motivating example of Fig. [3] After the first round of liveness analysis followed 
by points-to analysis, we discover pair (p, r) in Ain^. Thus r becomes live requiring a 
second round of liveness analysis. This then enables discovering the points-to pair (r, s) 
in node 6. Note that the result is consistent with the observation made in Section f32\ 
towards the end. A comparison with the result of the default may-point-to analysis 
(Fig-0 shows that our analysis eliminates many redundant points-to pairs. 

Independent Must-points-to Analysis is Redundant. The explanation of KHI n and 
Must highlights why must-points-to analysis need not be performed explicitly. With the 
provision of Lin n x {?} as Bl, if we have a single points-to pair (x, y) with y ^1 for 
pointer x in Ain n or Aout n , it is guaranteed that x must point to y. Conversely multiple 
points-to pairs associated with a given variable means that the must-points-to informa- 
tion for this variable is empty. Hence must-points-to information can be extracted from 
may -points-to information by Uin n = Must(Ain n ) and Uout n = Must(Aout n ). Note 
that generally Uin n C Ain n and Uout n C Aout n ; the only exception would be for 
nodes that are not reached by the analysis because no pointer has been found to be live. 
For such nodes Uout n , Uout n are P x V whereas Aout n , Aout n are 0; this matches 

at n and so a solitary pair (x, z) also reaching n is not incorrectly treated as a must-points-to 
pair. 



10 



int flint a, int b) 

{ int *x, *y ~ Sza; // x = '?' 

int c — a * b; 
p: *x = 5; // Illegal write 

q: *y — 6; // Should kill avail(a * b) 

return c + (a * b); 

} 



- Def p = 0. 

- Liveness of y is killed. 

- Points-to information of y is empty 
(monotonicity of Must requires this). 

- Statement q cannot kill availability of a * b. 

- The return value will be mis-optimised into 
c + c. 



Fig. 6. Motivating the need for a sanity check for programs with undefined behaviour. 



previous frameworks and is necessary to make Must anti-monotonic (see ( fTTT ) in Sec- 
tional as is required by the the data flow equations in Fig. [4] Note that these definitions 
avoid the interdependent fixed-point computation of 111 1161 . 



3.4 Design Choices in Formulating Lazy Pointer Analysis 

We have chosen not to compute liveness of non-pointer variables (keeping them in 
V P) primarily for simplicity and efficiency of implementation. While we could in 
principle regard these as members of P which may be live but can never point to any- 
thing, this does not help discovering points-to information. 

In our formulation, data flow value '?' plays an ambiguous role: it represents an 
uninitialised pointer value, but it is left unclear whether this means "points to some 
variable in V" or "may be a wild pointer as in C". We have formulated the analysis as 
if for Java; an assignment *x=y can be assumed only to write to a non-'?' member 
of the points-to set of x — writes to '?' raise an exception. In C however, writes via 
uninitialised pointers can write to any location in memory, including all user variables. 
There are two ways to address this. Firstly, we can treat '?' as not standing for a single 
pointer value, but instead being a set of locations including V. While formally most 
correct, this requires modification of data flow equations in Fig. [4] for example to Must. 

Alternatively, and this is the course we have followed (because it gives more op- 
timisation opportunities), we can optimise a C-like program as if no dereferences or 
assignments via invalid pointer may occur at run-time, but add a "sanity check" to stop 
invalid optimisations when an illegal pointer assignment necessarily happens. This is 
possible because the semantics of both C and Java is that code after an assignment via 
an illegal pointer is effectively unreachable. In Java an exception is raised so the follow- 
ing code is not reached. In C the behaviour is "undefined" so the code can do what it 
wants, which includes "being mis-optimised" as a special case. However, the possibility 
of mis-optimisations arising out of a wild write can be detected. We observe that such 
a situation cannot arise in programs in which every pointer is defined along some path 
before being dereferenced — it is just the guaranteed dereference of '?' which causes the 
problem. Corollary Q] in Section [4] asserts this formally. Hence as the final step in our 
analysis we perform a sanity check: there must be no statement *x = y for which Def n 
is — otherwise optimisation is disabled. Fig.|6]provides an example that motivates this 
sanity check as a form of data-flow-anomaly warning (for indirect assignments via a 
variable with no valid pointees). 
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Since a is live at the exit of 2 and 3, pairs (a, 6) and (a, c) 
are generated which causes b and c to be marked live in 
5. Hence Loute = LouU = {a, b, c}. 
However, b is not live along path 1-3-4-5 because 
(a, b) (jL Aouti. Similarly, c is not live along path 1-2-5 
because (a, c) Aout2- 

Due to this imprecision in liveness, we generate the pair 
(b, e) in 3 which is then propagated to 5. This is spurious 
because there is no use of b anywhere along this path. 



Fig. 7. Imprecision in lazy pointer analysis due to indirect liveness. 

In our formulation, liveness is generated from points-to information as indicated 
by the presence of Ain n {y} in Ref n for the statement x = *y in Fig. |4] This leads 
to imprecision in liveness information which in turn leads to imprecision in points-to 
information as illustrated in Fig. [7] This imprecision can be avoided by exploiting the 
mutual dependence of liveness and points-to information: i.e. propagation of indirect 
liveness should also be restricted to appropriate points-to propagation paths — in the 
same way that propagation of points-to pairs is restricted to liveness paths. We omit this 
formulation (which is not used in the implementation) for space reasons. 

4 Properties of Lazy Pointer Analysis 

In this section we show that lazy pointer analysis is monotonic, sparse, and discovers 
all pointees of a pointer variable where it is used. Proofs are provided in AppendixlAl 

Monotonicity of Lazy Pointer Analysis The extractor functions Def n , Pointee n , 
Kill n (and Must) use points-to information. Besides, Ref„ uses liveness information 
also. In order to argue about monotonicity, we parameterise the extractor functions with 
the required information and drop the subscript n. 

Recall that the lattice of points-to information is A = (V(P X V), D). The follow- 
ing results hold Vv € Vand Vox, aa G A such that ax E 0-2 (i.e. ax 3 0*2)'- 



ai{v} 2 a 2 {v} 


(follows from the definition) 


(7) 


(ax ai){v} D (a2 ° 0,2) {v } 


(follows from the definition) 


(8) 


De/(ax) D Def{a 2 ) 


(follows from (|7]i) 


(9) 


Pointee(ai) D Pointee(a 2 ) 


(follows from ©) 


(10) 


(Must (a!)) {v} C (Must(a 2 )) {v} 


(follows from (O and (Q) 


(11) 



Theorem 1. Define the liveness flow function Jl-CxA^-C (Equation^} and the 
may-points-to flow function Ja'-CxA^-A (Equation® as: 

f L (l,a) = (l- Kill (a)) U Ref(l,a) 

f A (l,a) = (a- (Kill (a) x V)) u (Def(a) x Pointee (a))\i 

Then, /l and f a ore monotonic. 



kb 



z 



d — *a 



use d 



12 



Sparseness of Lazy Pointer Analysis Lazy pointer analysis is a form of sparse data 
flow analysis: the analysis is only done on live ranges rather than everywhere (contrast 
the previous use of the term to mean "along def-use chains"). 

Equations (01 and identify liveness paths for variables representing control flow 
paths in the program along which variables are live. For a given variable x, a liveness 



path is defined as a maximal sequence of statements s\, S2, ■ ■ ■ ,Sk satisfying the fol- 
lowing conditions: 

-xeRef Sk . (LI) 

- Si+i e succ(si), 1 < i < k. (L2) 

- x g Kill Sz , x e Lin Si , 1 < i < k. (L3) 

- x e Lout Sz , 1 < i < k. (L4) 



(LI) represents generation of liveness of x, (L2) insists on the sequence being a control 
flow path, while (L3) and (L4) ensure that the sequence is a modification free path. 

Equations (O and (0 identify propagation paths for points-to pairs representing 
control flow paths in the program along which points-to pairs are propagated. For a 
given points-to pair (x, y), a propagation path is defined as a maximal sequence of 
statements si, s 2 , • • • , satisfying the following conditions: 



- (x, y) e {Def Sl x Pointee Sl ). (Al) 

- s i+1 g succ(si), 1 < i < k. (A2) 

- (x, y) e Ain Sz , x ^ Kill Sz , x G Lin Si , 1 < i < k. (A3) 

- (x, y) e Aout Si , x e Lout Si , 1 < i < k. (A4) 



(Al) represents generation of the pair (x, y), (A2) ensures that the sequence is a control 
flow path, while (A3) and (A4) ensure propagation along a modification free path. 

Theorem 2. Every propagation path for a points-to pair (x, y) is a suffix of some live- 
ness path for x. 

Sufficiency of Lazy Pointer Analysis At the program point of every use of a pointer 
variable, lazy pointer analysis discovers all pointees of the pointer variable. We first 
observe a useful relationship between KHI n and Def n . 

Lemma 1. ((KHI n ^ 0) A (Kill n ^ P)) => (Kill n = Def n ) . 

Theorem 3. If x S P holds the address of z E (V— {?}) along some execution path 
reaching node n, then x G Ref n => (x, z) G Ain n . 

Corollary 1. If all pointer variables are initialised with values of proper types before 
they are used, then for every indirect assignment *x = y, Def n 7^ 0. 

5 Interprocedural Lazy Pointer Analysis 

We use the call-strings method (Section|2]i to ensure flow- and context-sensitivity. Since 
it is a generic method orthogonal to any particular analysis, lifting an intraprocedu- 
ral formulation of an analysis to interprocedural level is straightforward. In our case, 
Lin n , Lout n and Ain n , Aout n become sets of pairs (<j, a), a G A and (a, a), I G L at 
the interprocedural level where it is a call string reaching node n. The final values of 
Ain n , Aout n are computed by merging the values along all call strings. 
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Terminating Call String Construction. We use data flow values 1 8 1 to terminate call- 
string construction instead of using a precomputed length as proposed originally Q. 
This approach discards redundant call strings at start p and regenerates them at end p 
for forward flows as follows (and the other way round for backward flows): 

- Representation. If two call strings a and a' have identical data flow values at start p , 
both need not be propagated within the body of p because the data flow values of 
both a and a' will undergo the same change and will remain identical at end p . 
More formally, Out $ tart p is now computed as follows: 



Out s t a rt p = {Rep((a,x),p) | (a,x) E /n sfartp } where, 

(a',x) (a',x) £ ln startp ,\a'\ < \tr\ 
(a, x) otherwise 



Rep{{<r,x),p) 



- Regeneration. At end p , we examine the representation performed at start p . If o 
represents a', the data flow value associated with a it is copied to a'. Thus, 

Out endp = {(a', y) | (a,y) e ln endp , (a' ,y) e Reg {{a,y) lP )} 
Reg{{a,y),p) = {(a',y) \ Rep {{a' ,x),p) = (a,x)} 

Representation partitions call strings into equivalence classes based on the data flow 
values associated with them. Regeneration recreates the represented call string and re- 
covers their values based on the partitions they belong to. 



Matching Contexts for Liveness and Points-to Analysis. Since points-to information 
should be restricted to live ranges, it is propagated along the call strings constructed 
during liveness analysis. However in the presence of recursion, we may need additional 
call strings for which liveness information may not be available. We explain below how 
this is handled. 

Let a a denote an acyclic call string (i.e. a call string for an interprocedural control 
flow path with no unfinished recursive calls). Let a c a l denote a cyclic call string which 
corresponds to an interprocedural control flow path with unfinished recursive calls; a 
denotes an acyclic sequence of call sites corresponding to unfinished recursive calls and 
i denotes the depth of recursion in the path. Then: 

- The partitioning information for every a a is available because either (a a , x) has 
reached node n in procedure p or a a has been represented by some other call string. 

- Assume that the data flow values of a c a l are different for i < k for some k > and 
the data flow values of a c a k and cr c a A;+: ' , j > 1 are identical. Then the partitioning 
information is available for only a c a k and a c a k+1 because the call strings o- c a k+ J , 
j > 1 are not constructed. 

Consider a call string a' reaching node n during points-to analysis. From the above 
observations about partitioning it is clear that, if a' is an acyclic call string then its 
partitioning information and hence its liveness information is available. If a' is a cyclic 
call string, its value may not be available if it happens to be er c a fc+: ' , j > 1. However, 
it is sufficient to locate the longest prefix of <7 c a fc+: ' and use its liveness information. 
This is illustrated below in our motivating example. 
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(X z)r (X (z ?))a I I \ (ciC 2 /ciC2C2,(w,x),(z,x))a 

\ A > Z )L {^,{ Z ,-))A (ci/CiC2,WZ)l , , \ / 9 ss 

■ .(ci, (w,x), (z,?))a 



start, 



(X,z) L | (A,(z,?))a 
2 



x = &y 



■s 



start„ 



(C!,WZ), 



(X,z) L 1 (A,(z,?))a 
3[ 



w = Szx 



{X,wz) L (X,(w,x),(z,?)) a 



ci 



(ci,iu«)z, ~^—(c 1 ,(w,x),(z,?)) A 



(ci,z) l 


r-(ci, («,?)> 


5 


ri 




(A,z)l 


.. (A, (*,?))* 


6 


print z 




(A,0)i 


| (A,0)a 


7 


endm 




(A,0)i 


(A,0)a 



(Ci, W)i 


(ci/cic 2 , (w,:e))a 


9| 


* 

= 


= w | 




(ci,«;z)z, 




(ci/cic 2 , 


10 


c 


2 




(ciC2,wa;)£ 


(cic 2 /cic 2 C2, (w,a;), 



(cic 2 , z)l 


,(C1C 2 /C1C2C2, (z, l))A 


11 


^2 




(ci, z) L 


(Cl/Cie 2 , (z, l))A 


12 


z = *z | 





end„ 



(ci/ciC 2 ,0)a 



(ci/ciC 2 , z)l 



( Ci ,(z,?))a — 

(ciC 2 /ciC 2 C2, (Z, x))a 



Fig. 8. First round of interprocedural liveness and points-to analysis on our example program. 
Liveness and points-to information is subscripted with L and A respectively. To avoid prolif- 
eration of symbols, set of live variables are represented as strings and '{' and '}' are dropped. 
Multiple call strings with the same data flow value are separated by a '/'. 



Motivating Example Revisited. For brevity, let I n and O n denote the entry and exit 
of node n. In the first round of liveness (Fig. [8), z becomes live at J 6 as (A, z)l, reaches 
13, 12, and 1 1 as (c\, z) £, becomes (C1C2, z)l at In, reaches 13 and gets represented 
by {c\,z)l. Hence [c\C2,z)l is not propagated within the body of p. (ciC2,z)l is 
regenerated at Jg, becomes (ci, z)l at Iio, becomes (ci, w)l at Ig. At Og, it combines 
with (ci, z) l propagated from /13 and becomes (ci, w z)l- Thus C\Ci is regenerated as 
(ciC2,w z)l at Is. (ci,w z)l reaches 4 and becomes (A, w z)l- 

In the first round of points-to analysis (Fig. [8J, since z is live I\, Bl = (A, (z, 1))a- 
(A, (w, x))a is generated at O3. Thus (ci , (w , x) , (z , ?))a reaches /g. This becomes 
(ci, (w,x), {z,x))a at Og and reaches as (C1C2, (w,x), (z,x))a at 7g. Since z is not 
live at Ig, (C1C2, (w, x))a is propagated to Ig This causes (C1C2C2, (w, x), (z, x))a to be 
generated O10 which reaches Ig and is represented by (c\C2, (w,x), (z,x))a- This is 
then regenerated as (C1C2C2, (z, x))a at O13 because only z is live at O13. Note that we 
do not have the liveness information along C1C2C2 but we know that it must be the same 
as the liveness information along c\C2- We get (C1C2, (z, x))a and (ci, (z, at On. 
Since we have no points-to information for x, we get {c\C2, 0)a and (ci, 0)a at Oi2- 

The second round of liveness and points-to analysis is presented in Fig. [9] We leave 
it for the reader to verify that x becomes live due to z — *z in 12, reaches 2 and causes 
(A, x)Ay to be generated. As a consequence, we get (z, y) in 12. 
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start„ 



(ci/cic 2 /cic 2 C2,x) L (ci/cica, (x,y)) A 

If 



x = &y 



8 



sfart„ 



(\,x) L I (X,(x,y)) A 



(ci/c 1 C2,x)l 



(ci, (x,y)) A 



W — kLX 



(X,x)l [ (X,(x,y)) A 
4 



Cl 



(ci.a;)! '— (ci, (ar,y))A- 
5 



9 

(ci/cic 2 ,a;)i 
10 

(cic 2 /cic 2 C2,a:)i 



] 



(ci, (x,y)) A 



XT 



J] 

(C1C 2 , (X, J/))a 



ri 






(X,(z,y)) A 


print z 






end m 


(< 



(cic 2 /cic 2 C2,a;)L 


r— (cic 2 , (a;,y), (z,i/))a 


\ 


11 


r 2 




(ci/ciC 2 ,2;)l 


, (ci, (z,y))A 




\ 3 


2: = *0 | 




x) L 




(Cl, (2,3/)U 


13 


endp 





(cic 2 /cic 2 c 2 ,2;)l (C1/C1C2, (z,y), («,3/))a 



Fig. 9. Second round of liveness and points-to analysis to compute dereferencing liveness and the 
resulting points-to information. Only the additional information is shown. 



This result corresponds to the observations in Section [TJ Note that (z, x) cannot 
reach 6 along any interprocedurally valid path. However, the method of [ 1 1 which is 
considered most precise flow- and context-sensitive method, computes (z, x) at 6. 



6 Related Work 

The benefits of flow- and context-sensitivity have been found to vary from marginal 
to large in the literature 0141151161171 . It has also been observed that an increase in 
precision could increase efficiency. However, studies have been inconclusive by and 
large and a large number of investigations relax flow- or context-sensitivity (or both) in 
their pursuit of efficiency in pointer analysis. Our premise is that the use of liveness en- 
hances the effectiveness of flow- and context-sensitivity significantly. A flow-insensitive 
approach cannot benefit from liveness. The use of liveness in context-insensitive ap- 
proaches has not been investigated. 

We focus on approaches that are both flow- and context-sensitive. A memoisation- 
based functional approach observes that the number of possible pointer patterns that 
reach a procedure are small and hence it is beneficial to use partial transfer func- 
tions [18] instead of the usual full transfer functions. An alternative functional approach 
creates full transfer functions but contains the complexity of computing transfer func- 
tions by making them sensitive to the "level" of a pointer (i.e. the possible depth of its 
indirection) [ 1 9 1 . Transfer functions for a given level are defined in terms of lower-level 
transfer functions. The invocation-graph-based approach unfolds a call graph in terms 
of call chains [10|. Our work is inspired by this approach but we have incorporated 
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strong liveness and manage contexts very differently. Finally, a radically different ap- 
proach proceeds in the opposite direction and begins with flow- and context-insensitive 
information which is refined systematically in cascaded steps to restrict it to flow- and 
context-sensitive information |20|. 

The above approaches summarise points-to information in recursive contexts using 
fixed-point iteration. This merges the information across different levels of nesting and 
all recursive calls receive the same summarised information. The call-strings approach 
maintains distinct data-flow values for each nesting depth of recursion. The partial- 
transfer-function-based approach [ 1 8 1 is slightly more precise than the invocation-graph- 
based approach [ 10 1 because it distinguishes the outer call to a recursive procedure from 
the calls inside the recursion. For example, in our motivating example, (z, x) holds only 
in the recursive calls of p. When recursion unwinds fully, z does not point to x. Our ap- 
proach discovers this correctly but 1 1 1 cannot do so. Fig. 9.6 (page 305) in |6| contains 
an example for which the methods in 01811011 compute imprecise results. 

GCC uses a context-insensitive analysis which acquires limited flow sensitivity due 
to the effect of SSA representation — a half-way house. However, SSA form does not 
apply to pointers directly and interleaved SSA construction and pointer analysis are 
required ||2T1 which is not done in GCC. Appendix|B]shows by example that the points- 
to information in GCC is effectively flow-insensitive. 

7 Implementation and Empirical Measurements 

We have implemented interprocedural lazy points-to analysis in GCC 4.6.0. It requires 
the command line switches -f lto -f lto-partition=none -f lipta to in- 
voke GCC's Link Time Optimisation (LTO), pass on the control flow and call graphs, 
and finally perform lazy points-to analysis on the constructed supergraph. This imple- 
mentation is available for download^ 

We have executed our implementation on SPEC CPU2006 Integer benchmarks as 
well as some programs from SPEC2000 benchmarks on a machine with 16 GB RAM 
running 8 processors (64-bit intel i7-960 CPU at 3.20GHz). The results of measure- 
ments are presented in Fig. [10] We compare three implementations: lazy points-to 
analysis (Ipta), simple points-to analysis (spta) and GCC's points-to analysis (gpta). 
The only difference between lpta and spta is that lpta uses liveness whereas spta does 
not — both are flow- and context-sensitive and use call strings with value-based termina- 
tion, gpta is flow- and context-insensitive (see Section|6]for more details about GCC's 
points-to analysis). All three methods use the same approach of handling arrays, heap 
locations, pointer arithmetic, function pointers, and field sensitivity. 

Both lpta and spta are naive implementations that use linked lists and linear searches 
within them. The main goal of these implementations was to find out whether liveness 
increases the precision of points-to information. Our measurements confirm this hy- 
pothesis beyond doubt. Surprisingly, the time measurements exceeded our expectations 
because we had not designed these implementation for time/space efficiency or scala- 
bility. We were able to run our implementations on programs of around 30kLoC but not 
on the larger programs. It is evident from the measurements that: 

5 htt£T77 www. cse . iitb . ac . in/grc/index . php?page=lipta 
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lpta = 
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GCC's PTA 
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Fig. 10. Empirical measurements. A '?' indicates that the analysis ran out of memory. Max#cs 
denotes maximum number of call strings at any program point for lpta. 

- Lazy computation of points-to pairs reduces the number of points-to pairs dramat- 
ically. Although we could observe this for programs of approximately 30kLoC, we 
have no reason to believe that the situation would be different for larger programs. 

- Lazy computation and sparse propagation of points-to pairs reduces execution time 
too and lpta out-performs gpta for most programs smaller than 30kLoC. That a 
flow- and context-sensitive analysis could be faster than flow- and context-insensitive 
analysis comes as a surprise to us. lpta shows that the actual data that we can gain- 
fully use is much smaller than what is generally thought to be. 

- A reduction in the number of data flow values enhances the effectiveness of value 
based termination of call strings and in most cases the number of contexts required 
for precise analysis is not exponentially large. Further, the maximum length of any 
call string never exceeded two digits. 

The hypothesis that our implementation suffers because of linear search in linked 
lists was confirmed by an accidental discovery: in order to eliminate duplicate pairs in 
gpta, we used our data structure and function from lpta that adds points-to pairs in a 
linked list and maintains a unique entry for each pair in the list. With this addition, gpta 
executed for well over an hour on the hmmer program whereas originally gpta needed 
246.3 milliseconds only! Since lpta uses linked lists to represent sets, it has to maintain 
uniqueness at each stage and this seems to be the primary reason why we could not 
execute it on the larger programs: gobmk, perlbench, and gcc. 

Eager liveness computation to reduce points-to analysis work could also be a source 
of inefficiency: a new round of liveness is invoked when a new points-to pair for y is 
discovered for x = *y putting on hold the points-to analysis. This explains the unusu- 
ally large time spent in liveness analysis compared to points-to analysis for programs 
parser and sjeng. The number of rounds of analysis required for these programs was 
much higher than in other programs of comparable size. 

Our implementation can be improved many ways. 
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- We can use efficient data structures (vectors or hash tables) supported by GCC. 
Alternatively, we can use BDDs to efficiently maintain sets of data flow values. 

- We can experiment with less eager strategies of invoking liveness analysis. 

- The LTO framework could be modified to load CFGs on demand. Currently, LTO 
gives one large program with all CFGs or just a call graph without CFGs. This 
results in a very large supergraph in memory — affecting locality (cache misses) 
partly explaining the 30kLoC threshold. 

- Our implementation performs full computations of liveness and points-to analysis. 
Revisiting a statement typically causes only a small additional amount of informa- 
tion to be generated. We posit significant savings by exploiting this third dimension 
of laziness: compute information incrementally on revisits. 

Apart from improving the implementation, another route to scalability lies in the ob- 
servation that 30kLoC seems to be a cross-over point: If we can preprocess programs 
to identify chunks of around 30kLoC which are very loosely coupled as far as pointer 
usage is concerned, we can expect this method to scale to much larger programs. 

8 Conclusions and Future Work 

We have described a data-flow analysis which jointly calculates points-to and liveness 
information. It does this in a flow- and context-sensitive way, using recent developments 
of the "call strings" approach. One novel aspect to our approach is that it is effectively 
bi-directional (such analysis seem relatively rarely exploited). 

Initial results from our naive prototype implementation were impressive: unsurpris- 
ingly our analysis produced much more precise results, but by an order of magnitude (in 
terms of the size of the calculated points-to information). The reduction of this size al- 
lowed our naive implementation also to run faster than GCC's points-to analysis at least 
for programs up to 30kLoC. This is significant because GCC's analysis compromises 
both on flow and context sensitivity. This confirms our belief that separating relevant 
information from irrelevant information can have significant benefits and is a promising 
direction for further investigations. 

We would like to take our work further by exploring the following: 

- Improving our implementation: e.g. using efficient data structures such as vectors 
or hash tables, or perhaps BDDs. Improving the interface to GCC's LTO framework 
by allowing the call graph to be loaded as a single unit, but then loading individual 
CFGs on demand so as not to keep the whole-program supergraph in memory at 
one time. 

- Exploring the reasons for the 30kLoC speed threshold; while interprocedural anal- 
yses are very likely to be super-linear in terms of the number of procedures, per- 
haps there are ways in practice to partition most bigger programs (around loosely- 
coupled boundaries) without significant loss of precision. 

- Currently our use of incremental computation is solely to avoid computing useless 
and imprecise data-flow information. However, we note that data-flow information 
often only slightly changes when revisiting a node compared to the information 
produced by the first iteration. We plan to explore incremental formulations of our 
lazy points-to analysis. 
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A Proofs of Lemmas and Theorems 

Theorem 1. Define the liveness flow function Jl'.CxA^C (Equation^} and the 
may-points-to flow function Ja'.CxA^A (Equation^} as: 

f L (l,a) = (/- Kill {a)) U Ref{l,a) 

f A (l,a) = (a - (Kill (a) x V)) U (Def(a) x Po/'nfee (a)) |/ 

Then, fi and j a are monotonic. 

Proof. Monotonicity of fa can be proved by showing that V(/i, a\), (l 2 , a 2 ) G C x A, 

(ii.ai) E (la, 03) (li - K///(ai)) 2 (| 2 - K///(a 2 )) (12) 
(h, ai) E (l 2 , a 2 ) =*> Ref(k,ai) D Ref(l 2 ,a 2 ) (13) 

( fT2l follows from (fTTT > while ( H"3l follows from Q. Monotonicity of can be proved 
by showing that V(/i, 01), (^2, 02) e£xi, 

(ii,ai) E (la, 03) (aa - (K7//(oi) x V)) D [a x - (Kill (02) x V)) (14) 
{h,ax) E Q 2 ,a 2 ) (Def(ai) x Pointee(ai)) D (Def(a 2 ) x Pointee{a 2 )) (15) 

(TT4l follows from ([11) while ([15) follows from (|9) and ([10). □ 

Theorem 2. £Very propagation path for a points-to pair (x, y) i's a smJ^x of some live- 
ness path for x. 

Proof. Consider an arbitrary propagation path p a for (x, y). Since L2 A2, A3 => L3, 
and A4 =>■ L4, it is easy to see that every statement n along p a must also be part of a 
liveness path for x. Let this liveness path be pi . Then the proof obligation reduces to 
showing that the last statement of p a must also be the last statement of p\. In other 
words, we need to show that 

CI. p a does not end somewhere in the middle of pi, and 
C2. p a does not extend beyond pi. 

We prove these by contradiction. For case (CI), assume that the last statement of p a 
appears somewhere in the middle of pi on position j. Consider statements Sj and Sj+i 
in pi such that Sj also appears in p a . From (L3) and (L4), in x G Lin s . , x G Lout s , and 
x G Lin Sj+1 . Also, x is neither in K/// s . nor KHI Sj+1 from (L3). Further (x, y) G /Wn Sj 
from (A2). 

(x, y) G Ain Sj A x ^ K/'// Sj A x G /-OUf ^ =>• (x, y) G /Aouf ^ 
(x,y) G /»Ot/f^ A x G Z-/n s . +1 => (x, y) G A'n Sj+1 

Thus (A3) is satisfied for Sj+i also. Hence p a is not maximal and can be extended to 
include Sj+i. This leads to contradiction. 

For case (C2) assume that the last statement of pi appears somewhere in the middle 
of p a on position j. Consider statements Sj and s 3 -+i in p a such that Sj also appears in 
pi. Then by conditions (A3) and (A4), x ^ K/'//^, x G Lout Sr and x G Lin Sj+1 . Thus 
Pi is not maximal and can be extended to include 8j+i. This leads to contradiction. □ 
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Lemma 1. ((K7//„ ^ 0) A (K7//„ # P)) => (Kill n = Def n ) . 



Proof. The lemma trivially holds for all statements other than indirect assignment *x = y. 
For the latter, 

((Killn ± 0) A (Kill n ^ P)) ((Ain n \ x ) ^ 0) A ((>tf#>„|J ^ {(a;,?)}) 

=s> (>4/n„ = {(.x,z)}) A(zeP) 

Hence KHI n = Def n = {z}. □ 

Theorem 3. If x £ P holds the address of z £ (V— {?}) along some execution path 
reaching node n, then x £ /-?ef„ =>■ (a;, z) £ /\/D n . 

Proof. Let the execution path reaching node n be denoted by p = sq, si, . . . , Sfc where 
so = Startp and = n. We prove the theorem by induction on path length k. The basis 
is k — 2 where s± assigns the address of z to x and S2 uses it@ Since a; £ Lin S2 , the 
sequence si, S2 is trivially both a liveness path as well as points-to propagation path. 
Thus, x £ Ref n (x, z) £ Ain n . 

Assume that the inductive hypothesis holds for k = i. Consider the case when 
k — i + 1. Note that x £ Lout Si . Statement Sj could influence x in the following ways: 

- x g 1 K/'// Si . Assume that the last node in path p in which x is assigned a value 
is s m , m < i. Statement s m either directly assigns &z to x, or does so through 
some variables in Ref Sm . By inductive hypothesis, the pointees of every variable in 
Ref Sm have been discovered in Ain Srn . Thus points-to analysis would discover that 
(x, z) £ Aout Sm . The suffix of p from s m to S{+i is both a liveness path for a; and 
points-to propagation path for (x, z). Hence (x, z) £ Ain n . 

- x £ K/'// Si . In this case, K7// Si could be Pif statement Sj is an indirect assignment 
*u> = ?/. Since w £ /-/n S; , by inductive hypothesis (w, u) £ Ain Si such that u 7^?. 
Hence the first condition of (f2]i cannot be satisfied. Thus this case is ruled out and 
Kill Si P. However since Kill Sz ^ 0, Kill Sz = Def Si = {x} from Lemma Q] By a 
reasoning similar to that of node s m in the previous case, (x, z) £ Aout Si . Since 
x £ Lin Si+1 , the sequence Si, s^+i is trivially both a liveness path as well as points- 
to propagation path. Thus, (x, z) £ Ain n . 

Thus the theorem holds because the inductive hypothesis holds for k = i + 1. □ 



Corollary 1. If all pointer variables are initialised with values of proper types before 
they are used, then for every indirect assignment *x — y, Def n 7^ 0. 

Proof. Since x £ Ref n , 3(x,z) £ Ain n such that z 7^? from Theorem [3] Thus Def n 
cannot be 0. □ 



When statement n uses *x, the minimum length should be k = 3 so that the pointee of pointee 
of x is also defined but this is not relevant at the moment. 
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B Flow Insensitivity in GCC's Points-to analysis 

Consider the following program: 

#include <stdio.h> 
int a, b, c, *e; 
int main ( ) 
{ 

if (a == b) 

e = & c ; 

else 

e = &b; 

e = &a; 
P() ; 

} 

P() 
{ 

printf ("%d", e); 

} 

In a flow sensitive analysis the points-to set of e will not contain a, b, c at the same 
time. There should be four different points-to sets associated with e: After nl and n2, 
it should be {c} and {b} respectively whereas it should be {b,c} before n3 and {a} 
after it. However, GCC computes a single points-to set for e that contains all three of 
them. The relevant fragment from GCC's dump is as follows: 

Points-to sets 
NULL = { } 

ANYTHING = { ANYTHING } 
READONLY = { READONLY } 

ESCAPED = { READONLY ESCAPED NONLOCAL a b C } 

NONLOCAL = { ESCAPED NONLOCAL } 

CALLUSED = { } 

STOREDANYTHING = { } 

INTEGER = { ANYTHING } 

e . 0_1 = same as e 

e = { ESCAPED NONLOCAL a b C } 

a. l_l = { ESCAPED NONLOCAL } 
a = same as a . 1_1 

b. 2_2 = { ESCAPED NONLOCAL } 
b = same as b . 2_2 

C = { ESCAPED NONLOCAL } 



/* statement nl */ 

/* statement n2 */ 
/* statement n3 */ 
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